Subject: Por que usar Engenharia de Software
From: <Salvo pelo Microsoft Internet Explorer 5>
Date: Fri, 4 Feb 2005 14:51:41 -0200

Uma Revisão sobre Engenharia de Software e sua Utilização no
Desenvolvimento de Sistemas de Prontuário Eletrônico de
Pacientes

Claudio Giulliano Alves da Costa, MD,

Rodrigo Paulo Quaresma, BE e Renato Marcos Endrizzi Sabbatini,
PhD.

Núcleo de Informática Biomédica, Universidade Estadual de
Campinas, Campinas/SP, Brasil

O desenvolvimento de um Prontuário Eletrônico de Pacientes
(PEP) deve ser norteado segundo metodologias preconizadas pela Engenharia de
Software (ES), que permitem uma perfeita organização do processo de
desenvolvimento, bem como um resultado final de altíssima qualidade. Este artigo
descreve brevemente a disciplina de ES, seus métodos, ferramentas e paradigmas,
enfatizando seu uso no desenvolvimento de PEPs. Assuntos como gerenciamento de
projetos, métricas, estimativas e estudo de viabilidade são discutidos; análise,
projeto, codificação, testes e manutenção são detalhados, citando-se os
principais métodos; e por fim, são feitos comentários sobre a garantia da
qualidade de software. Destaca-se ainda, a utilização das ferramentas CASE.
Desta forma, o intuito deste artigo é despertar a atenção da comunidade que
desenvolve soluções na área de saúde para a importância da ES no desenvolvimento
de PEPs.

INTRODUÇÃO

O desenvolvimento de sistemas de Prontuário Eletrônico de
Paciente (PEP) estão em pleno "vapor", diversas instituições e empresas, em todo
mundo, estão desenvolvendo suas soluções, muitas tem equipes especializadas que
produzem softwares de qualidade, outras, entretanto, não tem uma visão definida
do processo de desenvolvimento, e acabam produzindo sistemas de má qualidade
técnica, sem atingir as expectativas de usuários e diretores. No primeiro caso,
temos um processo de desenvolvimento que segue uma série de princípios
metodológicos; no outro, não.

O PEP deve ser entendido não somente como a informatização do
prontuário em papel, da mesma forma, ele não deve ser visto como um produto que
se pode simplesmente comprar e instalar. Na verdade, o PEP é um processo, que
deve ser desenvolvido gradualmente, utilizando metodologias para um
desenvolvimento seguro e eficiente. Tal como qualquer sistema, o desenvolvimento
de um PEP deve ser norteado segundo metodologias preconizadas pela Engenharia de
Software (ES), que permitem uma perfeita organização do processo de
desenvolvimento, bem como um resultado final de altíssima qualidade, ou seja, um
software em perfeito acordo com seus requisitos.

O objetivo deste artigo é assim descrever os principais
métodos, ferramentas e procedimentos na ES, destacando os seus principais
aspectos, numa tentativa de oferecer uma visão geral sobre esta área, para que
aqueles que estejam envolvidos no processo de desenvolvimento de um PEP, possam
efetivamente utilizar este paradigma para a melhoria do processo e do produto,
com benefícios diretos para a instituição, seus usuários e colaboradores.

ENGENHARIA DE SOFTWARE

Ainda que muitas definições abrangentes tenham sido propostas
para a ES, todas elas reforçam a exigência da disciplina de engenharia no
desenvolvimento de software, e abrange um conjunto de três elementos
fundamentais : métodos, ferramentas e procedimentos. Onde os métodos detalham
"como fazer" para se construir o software, as ferramentas proporcionam apoio
automatizado ou semi-automatizado aos métodos, e os procedimentos constituem o
elo de ligação que mantém juntos os métodos e as suas ferramentas, e possibilita
um processo de desenvolvimento claro, eficiente, visando garantir ao
desenvolvedor e seus clientes, a produção de um software de qualidade
1.

Por que usar Engenharia de Software ?

Nos últimos 20 anos, o hardware deixou de ser o item mais caro
na implementação de um sistema, enquanto que o custo relacionado ao software
cresceu e se tornou o principal ítem no orçamento da computação. Isso se deve
principalmente pela crescente complexidade dos problemas a serem resolvidos
pelos softwares. Sistemas como os de gestão hospitalar e sistemas de PEP chegam
a possuir milhões de linhas de código e envolvem vários especialistas para o seu
desenvolvimento 2. Aliado a
isso, alguns problemas inerentes ao processo de desenvolvimento de um software
começaram a surgir 1 : as
estimativas de prazo e de custo freqüentemente são imprecisas, a produtividade
das pessoas da área de software não tem acompanhado a demanda por seus serviços
e, a qualidade de software às vezes é menos que adequada, ocorrendo muito
freqüentemente a insatisfação do usuário. A chave para se vencer esses problemas
e dificuldades acima relatados é a larga utilização de uma abordagem de
engenharia ao desenvolvimento de software, aliada a uma contínua melhoria das
técnicas e ferramentas 1, 2,
no intuito também de melhorar a produtividade da equipe 2.

Dessa forma, podemos destarcar duas tendências para justificar
o uso da ES : primeiro, o software é um item de alto custo e em progressivo
aumento; e segundo, que os softwares têm um importante papel no bem-estar da
sociedade 3; dessa forma, a
ES assume papel crítico para garantir que tarefas, dados, pessoas e tecnologia
estejam apropriadamente alinhadas para produzir um sistema efetivo e eficiente
4.

PARADIGMAS DA

ENGENHARIA DE SOFTWARE

Um conjunto de etapas são definidas no processo de
desenvolvimento de um software, a esse conjunto de etapas denomina-se de
Paradigmas da ES 1.

Destacam-se 4 paradigmas principais 1,
5: o ciclo de vida clássico , a prototipação, o
modelo espiral e as técnicas de Quarta geração (4GT). Deve ser lembrado
ainda, que podemos combinar os paradigmas, obtendo-se um melhor resultado.

Figura 1 - Ciclo de vida clássico

Independentemente do paradigma a ser utilizado, 3 fases
genéricas dividem o processo de desenvolvimento 1 : Definição. Esta fase focaliza o
"o quê" (análise do sistema, planejamento do projeto de software e
análise de requisitos). Desenvolvimento. Focaliza-se o "como"
(projeto de software, codificação e realização de testes do software).
Manutenção. Concentra-se nas "mudanças" (correção, adaptação e
melhoramento funcional).

A Prototipação traz bons resultados principalmente
quando o cliente não tem precisão na declaração do problema. A construção de
protótipos em projeto de PEP deve ser extensamente utilizada, principalmente
porque estes são sistemas complexos, que necessitam de um alto nível de
colaboração do usuário no processo de desenvolvimento 6.

O modelo espiral é baseado no princípio do desenvolvimento
incremental, onde novas funções são adicionadas a cada ciclo. Análise,
especificação, projeto, implementação e validação são repetidas a cada ciclo,
gerando uma nova versão do software e permitindo um feedback mais imediato do
usuário 2.

As técnicas de quarta geração utilizam poderosas ferramentas
para o desenvolvimento do software, essas permitem um nível de especificação
mais elevado, próximo à linguagem natural, sendo capazes à partir dessas
definições, gerar o código-fonte do sistema 1.

GERENCIAMENTO DE PROJETOS

O gerenciamento de projetos abrange todo o desenvolvimento,
sendo praticado em cada etapa do processo. Uma das primeiras atividades de
gerenciamento é o chamado Estudo de Viabilidade. Sua proposta é
justificar a necessidade para o desenvolvimento do sistema, tanto do ponto de
vista técnico e organizacional como financeiro (custos), através do estudo de
índices como Retorno sobre Investimento 7. No gerenciamento, deve-se destacar o uso das
métricas de software que são usadas para medir a qualidade dos softwares
e controlar a produtividade dos projetos 5. As métricas podem ser categorizadas como
diretas ou indiretas; da produtividade, da qualidade e técnicas; e ainda em
orientadas ao tamanho (LOC), à função (FP - Function Point) e às pessoas
8.

O planejamento, como atividade de gerenciamento, deve ocorrer
baseado em estimativas seguras, e em geral, estas possuem a experiência
passada como único guia. Daí surge a necessidade de efetivamente usarmos
métricas de software, para construirmos uma grande base de informações, para que
possam ser utilizadas em projetos futuros. Diversos modelos empíricos de
estimativa foram desenvolvidos, destaca-se o COnstructive COst MOdel (COCOMO)
3 e o modelo de estimativa de
Putnam. Há também modelos de gráficos para o controle do cronograma do projeto,
tais como o de Gantt e o PERT 4 .

O número de artigos que tratam de gerenciamento de projeto, em
assuntos como métricas, estimativas, análise de riscos, dentro de um projeto de
PEP são extremamente escassos. Acredita-se que isso seja por falta de
publicação, mas se pode também imaginar que seja por desconhecimento dessas
técnicas, ou que elas sejam, simplesmente, ignoradas.

ANÁLISE DE REQUISITOS e

ESPECIFICAÇÃO

Os requisitos referem-se às necessidades dos usuários. É de
fundamental importância a compreensão total dos requisitos dos software para se
obter sucesso no desenvolvimento de softwares 1,
5. A análise de requisitos visa também garantir uma
estrutura de dados adequada, para que futuras aplicações, tais como estudos de
resultados clínicos, possam ser implementados e contar com todas as informações
necessárias 9. A
especificação é de suma importância, pois a maior parte dos erros encontrados
durante os testes e a operação dos sistemas são derivados de um pouco
entendimento ou má interpretação dos requisitos 5,
2.

Existem diversas técnicas para análise e modelagem de sistemas,
tais como : análise estruturada, análise orientada a objeto (OOA), modelagem de
dados, dentre outras. Atualmente destaca-se a OOA que introduziu uma série de
novos conceitos. A OOA traz vários benefícios, tais como : funcionalidades
complexas podem ser desenvolvidas com uma codificação menor e melhor; um rápido
desenvolvimento é alcançado comparado a outros métodos e as aplicações são
mantidas mais facilmente 7.

Com a evolução dos processos, sentiu-se a necessidade de se ter
uma linguagem unificada que se tornasse poderosa o suficiente para modelar
qualquer tipo de aplicação. Dessa necessidade, surgiu a UML (Unified Modeling
Language), uma linguagem padrão para especificar, visualizar, documentar e
construir artefatos de um sistema. Grandes grupos tais como o OMG (Object
Management Group) aprovam e estão envolvidos no processo de normatização desta
linguagem 10.

Hoje, a maioria dos sistemas de PEP utilizaram ou utilizam a
OOA, com vários trabalhos descrevendo o uso da OOA em PEPs 11, 12.

PROJETO e IMPLEMENTAÇÃO

Enquanto as especificações concentram-se no "o quê" a solução
fará, o projeto descreve "como" o software será implementado 8. É durante a fase de projeto que a estrutura
geral e o estilo são definidos 13. Segundo Pressman 1,
1995, essa fase do desenvolvimento, produz : um projeto de dados, um projeto
arquitetural e um projeto procedimental.

Além desses um projeto de interface distinto deve ser
elaborado, que estabelece o layout e os mecanismos para interação homem-máquina
1. Estudos tem demonstrado
que até 75% de todo o código da aplicação é destinada a interface, tamanha a sua
importância 2. O estudo da
interface com o usuário é de fundamental importância no desenvolvimento de PEPs,
onde uma interação adequada é necessária para adesão dos usuários ao sistema;
assim, conceitos como usabilidade e ergonomia, bem como uma série de
recomendações para a interface, tornam-se importantes para garantir o sucesso de
um sistema de PEP 14, 15.. O
ideal é que a interface seja intuitiva, fácil de usar e acessível para os
não-especialistas; para PEPs a interface deve ser adaptada ao método de trabalho
dos profissionais de saúde, e ainda ser capaz de representar os diversos tipos
de mídia representes na informação médica (texto, gráficos, imagens e sons)
2.

Da mesma forma que na análise, existem diversos métodos para o
projeto do software, cada qual com o seu conjunto de princípios e notações.
Dentre vários podemos citar : projeto orientado ao fluxo de dados, projeto
orientado a objeto (OOD), projeto estruturado e o desenvolvimento estruturado de
Jackson. Entretanto, o OOD atualmente tem tomado a atenção dos desenvolvedores,
que o têm utilizado largamente, e em conjunto, obviamente, com a OOA,
constituindo uma metodologia completa : a análise e projeto orientado a objeto
(OOAD). Vários trabalhos citam o desenvolvimento de PEP utilizando projeto
orientado a objeto 11, 12.
Com o OOAD é possível ainda a criação de Design Patterns e Frameworks. Design
Patterns são estruturas que aparecem repetidamente nos projetos orientados a
objeto para resolver um determinado problema de forma flexível e adaptável
dinamicamente, trazendo vantagens como : aumento da produtividade e da
consistência das aplicações, podem ser combinados para resolverem problemas mais
complicados e, a cada dia, surgem novos padrões que enriquecem o leque de opções
para o desenvolvedor. Um Framework pode ser considerado como uma infra-estrutura
de classes que provêem o comportamento necessário para implementar aplicações
dentro de um domínio específico, funcionando com um molde para as aplicações
16. Espera-se que no futuro,
possa se contar com um grande número de Design Patterns e Frameworks para a
construção de PEPs, e que aqueles que o desenvolverem compartilhem com toda a
comunidade de desenvolvedores.

Após o projeto, segue-se a codificação, também chamada
de implementação. Esta fase é uma simples questão de tradução do projeto para um
código, já que as decisões mais difíceis já foram tomadas durante a fase de
projeto 13. Temos hoje as
ferramentas RAD (Rapid Application Development) que permitem ao usuário um
rápido desenvolvimento, baseado em conceitos de reusabilidade e componentização.
Java, Visual Basic, Delphi e C++ são algumas das linguagens de programação mais
usadas atualmente. Além disso, tecnologias para o desenvolvimento de sistemas na
Web tem tido um crescimento exponencial.

TESTE DE SOFTWARE

Várias estratégias de testes podem ser implementadas para
assegurar que o software está realmente em acordo com suas especificações e
livre de erros. Teste de unidade, teste de integração, teste de sistema, teste
de instalação e teste de aceitação são exemplos de técnicas que podem ser
utilizadas 8. Temos ainda o
chamado alfa-test onde o software é testado num ambiente controlado por
alguns usuários e na presença dos desenvolvedores; e o beta-test, onde o
software é testado por um conjunto maior de usuários, que se propõe a dar um
feedback aos desenvolvedores caso alguma irregularidade seja encontrada. Já
existem ferramentas de software que automatizam o processo de teste.

MANUTENÇÃO

Em geral, a manutenção de software usualmente consome mais que
60% do custo no ciclo de vida de um software, sendo isto devido ao fato de que
os programadores, freqüentemente, são negligentes durante as fases do
desenvolvimento do software, tais como análise e projeto 5. Dessa forma, para uma manutenção mais
tranqüila e segura, deve-se utilizar extensamente a ES que garantirá um design
adequado e escalável para futuras modificações. Durante a manutenção, são
realizadas atividades corretivas, adaptativas, perfectivas e preventivas. A
manutenção de um sistema de PEP deve ser feita de maneira criteriosa, para
evitar que alterações inseridas venham a prejudicar o funcionamento do sistema e
incorra em erros que podem causar sérios danos, principalmente ao paciente, como
por exemplo, a disponbilização de informações incorretas.

QUALIDADE DO SOFTWARE

A ES é a responsável pelo controle da qualidade do software,
fazendo com que este atenda a todos os requisitos e atributos 5, assumindo assim papel crítico na produção
dos sistemas. A garantia de qualidade de software (Software Quality Assurance
– SQA) é uma atividade que deve ser aplicada ao longo de todo o processo de
ES; envolvendo revisões técnicas formais, múltiplas fases de teste, controle da
documentação de software e das mudanças, um procedimento para garantir a
adequação aos padrões e mecanismos de medição e divulgação 1.

A avaliação de um sistema de informação médico, como um PEP,
por exemplo, é um processo que deve ser feito por toda a "vida" do software,
devendo-se avaliar itens como : performance, custo-efetividade, aceitação do
usuário e segurança 17.

Uma metodologia mais forte e organizada para a avaliação da
qualidade que está em expansão é o CMM (Capability Maturity Model), que
estabelece níveis de maturidade no processo de desenvolvimento 18.

FERRAMENTAS CASE

Nos últimos anos, com a crescente complexidade das metodologias
da ES, surgiram as ferramentas CASE (Computer-Aided Software Engineering). Elas
ajudam o desenvolver em todo o processo de desenvolvimento, desde o
gerenciamento, análise, e algumas até mesmo na codificação.

Entretanto, o uso dessas ferramentas ainda é pequeno,
principalmente nos projetos de PEP, como pode ser observado pela escassa
literatura sobre o assunto. É importante se destacar que as ferramentas CASE
aumentam a produtividade no desenvolvimento de grandes projetos de sistemas de
informação em saúde 19. O
projeto HELIOS é um excelente exemplo para um ambiente de ES para o
desenvolvimento de sistemas médicos, uma iniciativa que deve ser seguida
20.

CONCLUSÃO

O uso da ES é uma tarefa difícil e extensa, recheiada de
métodos, que tornam sua utilização uma atividade para especialistas. Entretanto,
não se deve relegar sua aplicação.

A importância da computação na sociedade moderna tem aumentado
o significado do conceito de qualidade de software. Dessa forma, o
desenvolvimento de softwares é hoje uma tarefa fundamental e, em muitos casos,
de missão crítica.

Como vimos, para a construção de softwares de qualidade, uma
série de etapas precisam ser seguidas. Um sistema de PEP precisa de vários
passos para o seu desenvolvimento, com uma detalhada análise de requisitos,
escolha de um modelo adequado, hardware e software para o auxílio do
desenvolvimento, projeto de interface bem definido, os fatores humanos
considerados, fazer com que os usuários participem efetivamente do processo de
desenvolvimento, para que tudo, em conjunto, produza um software de qualidade,
confiável e, assim, obtenha sucesso.

Hoje, encontramos um panorama bastante preocupante no
desenvolvimento de sistemas de informação em saúde, e principalmente sistemas de
PEP, pois a maioria das instituições e pessoas envolvidas no processo, não estão
utilizando nenhum dos paradigmas da ES, relegando um forte conjunto de
atividades que assegurariam a qualidade do produto. Isso tem influência direta
na qualidade da assistência à saúde dos pacientes : "softwares ruins,
informações ruins".

A busca para uma melhor assistência de saúde e a crescente
implementação de PEPs tem gerado e irá gerar cada vez mais, uma intensa demanda
por profissionais com habilidades em produzir software de qualidade, e portanto,
com profundos conhecimentos em ES.

O intuito deste artigo foi assim, despertar a comunidade de
desenvolvimento de sistemas de informação em saúde, ou seja, médicos,
engenheiros, analistas, informatas em geral, para a ES. Procurou-se oferecer um
breve panorama sobre como a disciplina deve ser aplicada, seus recursos,
paradigmas, métodos, e principalmente, tentou-se demonstrar as vantagens em se
utilizar a ES no processo de desenvolvimento de um sistema de PEP, enfantizando
a melhoria da qualidade dos processos e produtos gerados, com o objetivo final
de melhorar a qualidade da assistência à saúde prestada.

REFERÊNCIAS

Pressman, R.S. Engenharia de Software. São Paulo : Makron Books, 1995.

Degoulet, P., Fieschi, M. Introduction to Clinical Informatics. New York :
Springer-Verlag, 1997.

Boehm, B.W. Software Engineering Economics. Englewood Cliffs :
Prentice-Hall, 1981.

Murphy, G.F., Hanken, M.A., Waters, K.A. Electronic Health Records :
Changing the Vision. Philadelphia : W.B. Saunders Company, 1999.

Ramamoorthy, C.V., Prakash, A., Tsai, W.T., Usuda, Y. Software Engineering
: problems and perspectives. Computer. Outubro 1984. P.191-209.

Adelhard, K., Eckel, R., Holzel, D., Tretter, W. A prototype of a
computerized patient record. Comput Methods Programs Biomed 1995 sep-oct;
48:115-9.

Davis, M.W. Computerizing Healthcare Information : Developing Electronic
Patient Information Systems. Revised edition. New York: Mcgraw-Hill, 1998.

Von Mayrhauser, A. Software Engineering: Methods and Management. San Diego
: Academic Press, 1990.

Dolin, R.H. Outcome analysis: considerations for an electronic health
record. MD Comput 1997 jan-feb;14(1):50-6.

Furlan, J.D. Modelagem de objetos através da UML. São Paulo : Makron
Books, 1998.

Egyhazy, C.J., Eyestone, S.M., Martino, J., Hodgson, C. Object-oriented
analysis and design: a methodology for modeling the computer-based patient
record. Top Health Inf Manage 1998 aug;19(1):48-65.

Krol, M., Reich, D.L. Object-oriented analysis and design of a health care
management information system. J Med Syst 1999 apr;23(2):145-58.

Rumbaugh, J., Blaha, M., Premerlani et al. Modelagem e projetos
baseados em objetos. Rio de Janeiro : Editora Campus, 1994.

Sittig, D.F., Kuperman, G.J., Teich, J.M. WWW-based interfaces to clinical
information systems: the state of the art. Proc Amia Annu Fall Symp
1996;:694-8.

Ash, J.S. Factors affecting the diffusion of the computer-based patient
record. Proc Amia Annu Fall Symp 1997;682-6.

Apostila Orientação a Objetos : Da teoria à prática em Java.
CCUEC/Unicamp. (http://www.ccuec.unicamp.br).

Perreault, L.E., Wiederhold, G. System Design and Evaluation. In :
Shortliffe, E.H., Fagan, L.M., eds. Medical Informatics : Computer
Applications in Health Care. New York : Addison-Wesley Publishing, 1990.

Software Engineering Institute - CMM (Capability Maturity Model) :
http://www.sei.cmu.edu.

Lee, F.W. Can computer-aided systems engineering tools enhance the
development of health care information systems? A critical analysis. Top
Health Inf Manage 1996 aug;17(1):1-11.

Degoulet, P., Jean, F.C., Meinzer, H.P. et al. The HELIOS medical
software engineering environment. Comput methods programs biomed 1994
oct;45(1-2):91-5.